System and method for transition of association between communication devices

ABSTRACT

A system and method of providing an assignable registration between a device and a user for IP telephony, wireless telephony and other forms of collaborative systems is provided wherein loss of association is detected and a policy language is used to capture and execute user preferences in the event of such loss. A method and system are also provided for utilizing coupling between a thin client and a telephone to provide for device association.

FIELD OF INVENTION

The specification relates generally to networked devices, andspecifically to a method and system for transition of associationbetween communication devices.

BACKGROUND OF INVENTION

Personal mobility is a hallmark of modern communications. For example,associations may be provided between networked devices and other typesof collaborative systems, such as IP phones, thin clients, PCs/laptopsusing “hot desking” and wireless access to provide user selecteddynamically associated features and preferences via a physical piece ofhardware (i.e. device) that connects the user to the network.

It is important that users be able to maintain connectivity as they movethrough different environments during the course of day-to-dayactivities. The ability to create associations between a user and adevice by means of hot desking, IP telephone registration, localwireless and cellular service registration etc. is well known. Howeverthe expected behavior of an existing call, or other collaborativesession, in circumstances where an association is terminated, remainsundefined. For example, in the case of hot desking, if an associationbetween device and user is ended but a call involving that device anduser is still active, conventional IP systems will maintain the currentcall on the same device thereby coupling the association of the callwith the device, whereas it is possible that the user may want the callto proceed on another device if the association is terminated.

As but one example, a user may be involved in a call on a device in onelocation (e.g. a meeting room) and during the course of the call maywish to move to another location (e.g. office desk) to be able to accessother information or personnel. It is not presently possible for theuser to end his/her association with the device, move to another deviceand register on the new device while maintaining his/her current callthroughout the transition. The foregoing is an example of auser-initiated, controlled transition of association.

However, there are also cases in which a transition or loss ofassociation is uncontrolled. For example, in IP telephony it is possiblefor a device in the underlying access network linking a device to thebackbone network to cause the association to fail. Also, loss ofassociation may occur between WiFi and DECT devices connected to anin-building wireless system as a result of the user entering a wirelessdead zone or moving out of range of a wireless antenna.

It would be desirable in such situations for a user to indicate his/herpreferences on how such losses of association are to be dealt with (i.e.as an alternative to dropping the call). Moreover, it would be desirableto provide a mechanism by which a user may indicate preferences on howcall association should be maintained for both controlled anduncontrolled transitions of association, and a mechanism to implementthese preferences.

It is common in IP telephony systems to provide user proxies forapplying user-selected features and preferences to incoming calls.Proxies function to direct incoming calls to an endpoint that is most incompliance with declared user preferences. For purposes of mobility,users are able to register a number of endpoints at which they can bereached. Existing technologies, such as CPL (Call Processing Language),permit a user to specify preferences for the handling of incoming calls.CPL is a network protocol agnostic (described in RFC3880), commonly usedin conjunction with SIP (Session Initiation protocol), and uses an XMLmark up language that allows a user to specify the handling of incomingand outgoing calls. The user can specify conditions on classes ofoffered calls (as indicated by SIP address, time of day, etc) and CPLuses these classes to direct the calls to certain endpoints. It is alsoknown to couple CPL to a policy system for allowing user-control in amore straightforward manner through the use of structured Englishsentences.

Table 1 is reproduced from the CPL RFC (RFC 3880, FIG. 2), as follows:

TABLE 1 <?xml version=“1.0” encoding=“UTF-8”?>  <cplxmlns=“urn:ietf:params:xml:ns:cpl”  xmlns:xsi=“http://www.w3.org/2001/XMLschema-instance”  xsi:schemaLocation=“urn:ietf:params:xml:ns:cpl cpl.xsd ”>   <subactionid=“voicemail”>    <location url=“sip:jones@voicemail.example.com”>    <redirect />    </location>   </subaction>   <incoming>   <address-switch field=“origin” subfield=“host”>     <addresssubdomain-of=“example.com”>      <location url=“sip:jones@example.com”>      <proxy timeout=“10”>        <busy> <sub ref=“voicemail” /> </busy>       <noanswer> <sub ref=“voicemail” /> </noanswer>        <failure><sub ref=“voicemail” /> </failure>       </proxy>      </location    </address>     <otherwise>      <sub ref=“voicemail” />    </otherwise>    </address-switch>   </incoming> </cpl

The CPL script of Table 1 uses an address switch to determine if anincoming caller is from the “example.com” domain. If so, the call isproxied to the endpoint identified by the SIP address jones@example.com.If that call fails, or goes to busy or times out after 10 seconds, thecall is directed to the user's voicemail. For all other callers (i.e.those not from example.com), the CPL script provides no specificationfor call disposition and so the default behavior of the proxy isfollowed.

There is no provision in the SIP specifications (RFC3251) or CPL thataddresses the situation where the device on which a call is beingconducted loses its registration. However, as indicated above, in thevery similar case of a conventional PBX hot desking feature, if the hotdesk registration is withdrawn during the time that a call is active, itis common to maintain the call on the current device until a disconnectsignal is received. This default call handling assumes that the userwill remain at the device and will wish to continue the call on thedevice. However, as discussed above, this assumption is not valid inmany cases of controlled or uncontrolled loss of association such thatdefault call handling may not adequately serve the user in suchsituations.

BRIEF DESCRIPTION OF THE DRAWINGS

Exemplary prior art and embodiments are described with reference to thefollowing figures, in which:

FIG. 1 depicts a prior art system for associating networkedcommunication devices using CPL with SIP;

FIG. 2A is a block diagram showing a system for handling loss ofassociation applied to local hot desking or IP telephone registration,according to an exemplary embodiment;

FIG. 2B is a block diagram showing a system for handling loss ofassociation applied to external hot desking, according to an exemplaryembodiment;

FIG. 2C is a block diagram showing a system for handling loss ofassociation applied to a local wireless connection in which a user witha roaming device may connect to a local network through a wirelessgateway, according to an exemplary embodiment;

FIG. 3 is a block diagram showing a system for handling loss ofassociation applied to a local wireless connection provided with adigital signal processor for detecting low voice quality on a localwireless connection, according to an exemplary embodiment; and

FIG. 4 is a block diagram of a system for handling loss of associationin between a thin client device served by a thin client server and anassociated telephone connected to a PBX coupled with a feature adjunct,according to a an exemplary embodiment.

DETAILED DESCRIPTION OF THE EMBODIMENTS

The typical configuration for the use of CPL with SIP is shown inFIG. 1. A proxy 100 is configured to work in conjunction with aregistrar 110 and an application server 120. The application server 120includes a processor and memory for implementing a user CPL document 130and CPL execution engine 140. A user is able to register multipledevices, such as device 150, with registrar 110. A user is also able toadd tags to these registrations to indicate the characteristics of thedevice for governing the type of calls that that can be accepted by thedevice from the network 160. For example, the user can identify the typeof media (e.g. audio, video, etc.) that the device can handle; whetherthe device is to be used for business or personal use; whether it isfixed or mobile, and so on. It is also possible that the device 150 canprovide such tags with information provided by the manufacturer orprogrammed by a network administrator/manager. The proxy 100 providesdefault behaviour for matching an incoming call INVITE to the mostsuitable endpoint on network 160 (e.g. other network devices 150′, 150″,etc.). The calling user may populate his/her INVITE message withACCEPT-CONTACT and REJECT-CONTACT headers that indicate the types ofendpoints that he/she either will or will not accept. The defaultbehaviour of proxy 100 matches the caller preferences to the types ofuser devices, for example as discussed above in connection with Table 1.

The association between user and device can take a number of forms tosatisfy user needs for different forms of interaction. FIGS. 2A through2C represent system aspects of a number of these forms. FIG. 2A is ablock diagram showing how an association can be performed for local hotdesking or IP telephone registration. FIG. 2B is a block diagram showinghow external hot desking can be created, wherein an external device 150is provided with services as if it were a local device 150′, 150″, etc.FIG. 2C is a block diagram showing a local wireless connection in whicha user with a roaming device 180 may connect to a local network 160through a wireless gateway 190.

In FIG. 2A, VoIP telephone registration is accomplished via a SIPregistration server 165 that may be included as part of the telephonedevice 150 or may be provided as a separate device or part of a separatedevice. Registration may be performed either manually or automatically.In the manual case, a user may enter information such as a user ID andPIN on a keypad of the device 150 or may enter the equivalentinformation on another device such as a personal computer or thin clientthat is associated with the telephone device 150. Data may also beentered via a smart card (e.g. magnetic stripe, RFID, JAVA card etc.)inserted in a card slot of the device 150 or read remotely by use of RFor magnetic technology. Automatic registration can be performed throughthe application of location or biometric technology such as thumb printdata, retina scan technology etc. For example, a user may be registeredon a meeting room telephone automatically if a location system (notshown) detects that the user is in the room. Alternatively, facialrecognition can determine the identity of a user who is at the locationof a telephone device 150 and in response automatically triggerregistration.

As discussed above, loss of association in the scenario of FIG. 2A maybe intentional, in which case the user may be desirous of maintainingthe current call and moving it to another device. This can occur in avariety of circumstances. A user may wish to move a call from a fixedtelephone in a meeting room to his/her local wireless or cellulartelephone so that he/she can maintain the call while moving. Anotherpossibility is that the user may wish to move the call from one fixedtelephone to another fixed telephone. For example, the user may be on aconference call in a meeting room and wish to move the call to his/herdesk telephone in order to access documents that reside in his/heroffice. A particular complication arises in the foregoing case in thatthere may be multiple users associated with the meeting room telephone(e.g. conference call). The user may wish to move his/her participationin the call to another device without affecting the other participants'interaction with the call in any way. In such a situation, the user mayremove his/her identity card from the device to end his/her associationbut wish the call to be preserved on the current device while he/shemoves to another device. Alternatively, it is contemplated that the usercould send a command to the system via the device 150 to remove his/herassociation (e.g. out-of-band digital message or a DTMF feature accesscode). In any event, the removal of user registration is reported to theregistrar 110 by the registration server 165 removing the registration.The registrar then sends an indication of the removal of registration tothe device 150 which is provided with default behavior resulting fromloss of association (i.e. in prior art SIP systems, since the CPLdocument provides no specification for call disposition, the applicationserver 120 follows the default behaviour associated with the proxy 100,to maintain the call association until a disconnect signal is received).

Registration of an external telephone 150 or other device in the exampleof FIG. 2B may be accomplished using the techniques described in forexample, U.S. Pat. No. 5,454,032, (incorporated by reference) byinitiating connection through the network to an External Hot DeskingUnit (EDHU) server 170. A user ID and PIN can be supplied forauthenticating a user with the EDHU server 170 to initiate aregistration of the user on the proxy 100.

Loss of association in the case of external hot desking, as illustratedin FIG. 2B, may result from an intentional user act similar to thatdescribed for local hot desking discussed above in connection with FIG.2A. However, loss of association may also be unintentional such as inthe case where there is a loss of connection between the remote site andthe EDHU server 170 due to a failure in the network 160′. In eithercase, the EDHU server 170 removes the registration from the registrar110 and the registrar reports this to the application server 120 fordefault call handling (i.e. maintain the current call on the same device150 thereby coupling the association of the call with the device).

Registration of association of a user wireless device 180 with thesystem in the example of FIG. 2C gives rise to a dynamic connection, asdiscussed above. A wireless protocol implemented within gateway 190searches for and establishes communication with an available basestation through which the user can access the system. As the user movesand/or the RF environment changes, the device connection moves betweendifferent base stations, in a well known manner.

The variable state of the RF environment may cause loss of associationby the complete loss of connection between the user device 180 and thewireless gateway 190. This is similar to the loss of association due tonetwork failure for the external hot desking example of FIG. 2B.Likewise, when such a loss of connection occurs, the wireless service190 removes the registration of the wireless device 180 from theregistrar 110. Moreover, in wireless systems the RF environment cancreate situations in which wireless communication with the device 180 ispossible but the number of errors reduces voice quality to anunacceptable level. In such situations, it may be desirable to suspendthe current call and attempt reconnection to the user on a new channelthat has a better quality connection.

The various associations set forth in FIGS. 2A-2C provide differentmodes of communication between users. A user who is remote from theoffice accesses his/her colleagues and other communication equipmentaccording to a different mode than a user who is on the local network.Therefore, user options and preferences for coping with loss ofassociation will differ for each of the associations depicted in FIGS.2A-2C.

Moreover, as discussed above, loss of association may be intentional orunintentional on the part of the user. Loss of association can resultfrom circumstances beyond user control or can be initiated by the user.For example, the wireless configuration of FIG. 2C is notoriouslyfragile and it is not uncommon for wireless devices to lose connectionto the system. On the other hand, in the hot desking case of FIG. 2A, auser can remove his/her association with device 150 intentionally andwish the system to interpret this as an instruction to conform to userpreferences on how to handle the currently active call. The possibilityof intentional and intentional loss of association requires an abilityto specify multiple user preferences for behavior on loss ofassociation.

The following description of an exemplary embodiment refers to theexample of FIG. 2A, but is equally applicable to the examples of FIGS.2B and 2C, and FIG. 3. In the context of FIG. 2A, a method is set forthfor implementation within application server 120 to respond in the eventof loss of association according to user preferences set forth in apolicy language (referred herein to as extended CPL, set forth below)executed by execution engine 140 such that SIP proxy 100 is providedwith an appropriate user prescribed behavior in the event of loss ofassociation. Thus, the policy engine 140 and proxy 100 interact toprovide either a user prescribed or a default behavior.

As discussed above in connection with Table 1, the CPL policy language(RFC 3880) already functions to describe and enforce user preferencesfor both incoming and outgoing call attempts. This is done inconjunction with the default behaviour of proxy 100, which cooperateswith the application server 120 so that user preference scripts can beuploaded and otherwise managed. Consequently, the exemplary embodimentset forth herein builds on conventional CPL as a base to which newextensions are added and existing elements are modified to createappropriate loss of association behavior. Accordingly, the exemplaryembodiment of policy language set forth herein is referred to asExtended CPL or ECPL.

CPL provides for handling of user preferences relating to incoming andoutgoing calls by the elements <incoming> and <outgoing>, which delimituser preferences during these call states. However, losses ofassociation occur during the middle of a call (i.e. midcall). Therefore,a new element is set forth denoted as “midcall” to delimit userpreferences for the handling of events during the midcall state.

CPL is ambiguous as to the distinction between a call state and anevent. Specifically, CPL accommodates user preferences for outgoing andincoming call states but only a single event (the occurrence of anoutgoing or an incoming call) is supported in each of these states.According to ECPL, as set forth in greater detail below, multiple eventsmay be supported in the midcall state.

According to a first aspect of ECPL, there is provided an “event”element having a single attribute called Type. The value Type is used torepresent any one of multiple defined events. For example, as describedbelow, a single event called “loss_of_association” may be interpreted asa reported loss of association for any device. Other events, such as aspecific events denoting unacceptable RF performance, may also besupported, as discussed below. Additionally, DTMF reception events maybe used for manual removal of association, transfer or any appropriatemidcall feature.

According to a second aspect of ECPL, a “distant_switch” element isprovided for making decisions based on the identity of a distant partyor parties who are present in a call. As discussed above in connectionwith Table 1, the existing CPL specification provides an address switchthat can make decisions on various fields within the origin anddestination addresses of the INVITE message for an incoming or outgoingcall attempt. By use of various subfields, switching may occur by username (using the user subfield) or affiliation (using the host subfield).However, for midcall events the distinction between an incoming andoutgoing call attempt event is not valid. Therefore, the“distant_switch” element of ECPL makes decisions based on the identityof the distant party of parties who are present in the call. Variousparameters are set forth herein to facilitate this identification,including “name” and “affiliation”, wherein the execution engine 140accesses a directory (not shown) containing a linkage between theaddress and the names and affiliations of a user's contacts. Theapplication running in engine 140 is therefore aware of the address towhich a call has been set up and uses that address to extract the name,affiliation, etc. of the distant party in a call. As discussed ingreater detail below, comparisons are made with strings that areassociated with the above-described parameters such that if the stringis contained within the parameters a match is made.

Location is a currently defined tag within the CPL specification formanaging a list of URIs to which a device is programmed to be proxied,redirected, etc. Location is always specified as an explicit URI. For ofthis disclosure, it is assumed that connections are moved from onedevice owned by the user to another device owned by the user. It istherefore desirable that the user be able to specify the device in amanner that does not depend on its specific identity since the identitymay change as devices are registered and de-registered. For example, auser may have multiple mobile devices that are not all in usesimultaneously. In case of a loss of association from one such device,the user may wish to move the connection to one of his/her other mobiledevices. The user therefore registers these devices within his/hercontacts on the registrar 110. If specific URIs are required for“location” in the ECPL script then the user must ensure that the ECPLscript is updated with the same new contacts by means of locationelements. As a result of the ability to specify by class, the user inthis example need only specify a location of type “mobility”, and nointeraction is required between contact registration and the ECPL scriptmanagement. This provision also makes the selection process moreexplicit in terms of the types of services that are desired on the“moved” connection. Thus, a user may wish to move the association tohis/her secretary as specified by an “actor” parameter (discussedbelow). If the secretary assigned to the user changes during the day(e.g. lunch coverage, etc.), the complicated process of recognizing sucha change and updating the CPL script is avoided.

According to an exemplary embodiment, a URL parameter “self” is reservedto indicate that a specified device is among those already registered inthe user's contact list. As indicated above, a user is able to specifythe device by media feature tags to avoid complicated interactions withthe contact registration process.

According to the exemplary embodiment, the class of device is defined ina similar manner as the media feature tags contact list specification ofRFC 3840 (Indicating User Agent Capabilities in the Session InitiationProtocol (SIP)). Examples of tags defined in section 10 of that documentare:

Mobility—In RFC 3840, this has two possible values: “fixed” and“mobile”, which indicate whether or not the device is wireline orwireless. For the purposes of this disclosure, the value “mobile” hasbeen supplemented by values which indicate whether the wireless deviceis suited for local wireless or cellular service. According to theexemplary embodiment, the values are “local” and cellular”. Thus, whilethe values of “fixed” and “mobile” are retained, and “Fixed” maintainsthe same semantics as in RFC 3840, “Mobile” takes the semantics ofeither a local or cellular wireless device.

Class—this has two values with obvious implications: “business” and“personal” (e.g. a user would likely not want to move a call from abusiness associate to a personal device that a child might answer).

Actor—this has four possible values: “principal”, “attendant”,“msg-taker” and “information”. Principal indicates a device associatedwith the human user. Msg-taker is a person or device which can acceptmessages on behalf of the human user (e.g. a user voice mail box).Information refers to a device that can provide information about thehuman user (e.g. to supply information on the loss of association).Attendant is a device or human being which or who can assist incontacting the human user (e.g. a user's secretary who can assist theuser in regaining contact with the user).

Other tags are defined in section 10 of RFC3840 that may be of use inimplementing aspects of the invention. The list defined in RFC3840 isnot exhaustive and other tags may be defined, as would be understood bya person of ordinary skill in the art.

As discussed above, there are circumstances in which a user may wish tomove from one device to another while maintaining an association with acall-in-progress. For example, a user in a meeting room may wish to moveto his/her desk phone in order to continue the call while having accessto documentation accessible in the office. The movement of the call mustnot be instantaneous and must occur when the user reaches the new phone.This can be accommodated if the movement is directed to the nexttelephone that the user registers, rather than an existing telephone inthe contact list. Therefore, according to the exemplary embodiment,“Subsequent” is reserved in the location element to indicate the nextdevice on which the user registers.

The device that a user is using at the time of loss of association canbe indicative of the device to which the user will want the devicemoved. For example, a user may intentionally remove the association froma fixed device if he/she is desirous of moving the call to a mobiledevice. Consequently, a “device” parameter is provided according to theexemplary embodiment.

The CPL specification currently supplies proxy and redirect elements toindicate how a call being set up should be directed to an endpoint.These are unsuitable for the midcall case with which this disclosure isconcerned since, in the midcall case the reconnection must be handled insuch a way that other parties in the call will not be adversely affectedby the call movement. Proxy and redirect are used to set up a new call,not to work within an existing call.

First, in order to meet the requirement of not disturbing the existingcall, the new call leg must be connected to the current call in the sameway as the existing one. In this way, the same web of conferencing thatmarks large IP telephony calls will be maintained. Second, there arecases in which it is desirable for the existing call leg to bemaintained even though the call has been moved. One example of this is agroup of people interacting with a call by use of a speakerphone orconference unit. The current owner of the phone might wish to leave andmaintain contact by means of his/her wireless device. If the existingcall were to be dropped, the group of people on the conference would beinconvenienced. Also, it is known in the art to provide twinning of acell phone and a fixed device (e.g. “Mobile Extension” from MitelNetworks Corporation) to maintain the call on one of the cell phone anda fixed device while it is being moved to the other. Third, “proxied”and “redirected” calls will be subject to any feature treatment (e.g.forwarding, etc.) that is active at the remote location. In theembodiments discussed above, the user is directing the call to aspecific device and so would not want previously set up call treatmentsto interfere with his/her current direction. Thus, in certainembodiments, feature handling for these new connections will bedisabled. However, there may be cases in which legacy equipment is usedand this condition is not possible such that the user is required toensure that his/her preferences for loss of association are compatiblewith the feature treatments on the devices to which he/she will directcalls.

With these requirements, a new element is set forth according to theexemplary embodiment, denoted as “move”, to take an existing call legand extend it to the endpoint indicated in the location element. Thiscan be done by an internal switching capability within the proxy 100. Aparameter denoted “conference” is also provided that can assume a value“yes” to indicate that the new and extended call legs should beconferenced together or “no” to indicate that the existing call legshould be dropped. The proxy 100 can provide the conferencingcapability, as is well known in the art. The existing “timeout”parameter and “busy”, “timeout” and “failure” sub-elements of CPL andthe redirect elements are also supplied with the existing semantics.

In order to further describe the operation and use of the method andsystem for transition of association between communication devicesaccording to the exemplary embodiment, reference will be made to severalapplications.

In a first application, the exemplary method and system are applied toan intentional loss of association in which a user on a fixed telephone150 wishes to move the connection to his/her wireless telephone 180. Anexemplary ECPL script for implementing the midcall element is providedin Table 2, as follows:

TABLE 2 <midcall>  <subaction id = “subsequent”>  <location url =“subsequent”>   <move/ conference = “no”>   </location>   </subaction>  <event type = “loss_of_association”>   <device mobility = “fixed”>   <location url = “self” , mobility = “mobile”>     <move timeout =“10” conference = “yes”>      <busy> <sub ref = “subsequent”> </busy>     <noanswer> <sub ref = “subsequent”> </noanswer>      <failure> <subref = “subsequent”> </failure>     </move>     </location>    </event> </midcall>

In a second application, set forth in Table 3, below, the exemplarymethod and system are applied to handling a call on wireless device 180where there has been an unintentional loss of association, and whereinthe loss of association is handled according to the classification ofthe distant party.

Thus, with reference to FIG. 3, a configuration is shown for detectinglow voice quality on a local wireless call. The proxy 100 is involved inthe setting up of connections to all devices on which the user isregistered, as is known in the art. As discussed above, the SIPspecification (RFC3251) provides that registered devices may be suppliedwith classification tags. Among these is a tag that indicates that adevice is mobile. Additional tags may be added to indicate if the deviceis a local wireless or cellular device. For devices that are localwireless, the proxy 100 may be programmed to mirror the packet streamfrom the device 180 so that the packet stream goes both to the distantparty as well as to a DSP 195 for detecting poor voice performance.

The DSP 195 may use any of a number of techniques for detecting a poorwireless connection. First, the DSP is provided with a jitter buffer 197to receive the incoming voice packet stream. If the jitter bufferempties or if the number of queued packets varies more than apredetermined amount (as would be understood by a person of skill in theart), this provides an indication of errors resulting from the wirelessenvironment or from the network 160 connected to the wirelessenvironment due to congestion or other reasons. Alternatively, the DSP195 may detect a poor wireless environment in situations wherein thereceived voice is impaired by persistent bursts of noise. The DSP 195can use these and other indicators to report a loss of association tothe applications server 120.

In response, according to the exemplary script of Table 3, if the callis from a colleague in the user's company (“Mitel” in the example ofTable 3), there is no need for the call to proceed. The user'spreference is for the colleague to be provided with an announcement toinform his/her colleague that the call has failed. However, if the callis from a specific important customer (“John Doe” in the example ofTable 3), the user prefers that the call be sent to the user's cellulartelephone. If the user's cellular telephone is unavailable, the userwishes for the customer call to go to his/her assistant.

TABLE 3 <midcall> <subaction id = “assistant”>  <location url = “self”actor = “attendant” clear = “yes”>   <move/ conference = “no”>  </location>  </subaction>  <event type = “loss_of_association”>  <device mobility = “local”>    <distant_switch affiliation = “Mitel”>   <location url = “self” actor= “information” clear = “yes”>    </move>     </location>    </distant_switch>    <otherwise>    <distant_switch name = “John Doe”     <location url = “self”mobility = “cellular” clear = “yes”>      <move timeout = “10”conference = “no”>       <busy <sub ref = “assistant”>       <no answersub ref = “assistant”>       <failure sub ref = “assistant”>      </move>      </location>      </distant_switch>     </otherwise>    </distant switch>

A person of ordinary skill in the art will appreciate from the foregoingthat other elements of the ECPL specification may be used to furtherrefine the policies that guide behavior relating to loss of association.For example, the user may specify different performance by use of a timeswitch. A call may be moved to his/her assistant during normal businesshours and to an announcement otherwise. The user may also specifydifferent handling of his/her external hot desk telephone as opposed tohis/her local telephone. The user may request that a call be sent tohis/her local wireless device 180 in the event of loss of association onhis/her local telephone 150. Since this would not be of use for anexternal hot desk telephone (FIG. 2B), he/she may specify otherhandling.

The exemplary embodiment has been described above in terms of aSIP-based configuration. However, the principles set forth herein arenot restricted to SIP. For example, the system of FIG. 4 shows a thinclient device 400 (e.g. desktop computer) served by a thin client server410, and an associated telephone 420 connected to a PBX 430. The PBX 430is, in turn, coupled with a feature adjunct 440 via line circuits 450 toprovide line appearances and media looping, as is known in the art. Thetelephone 420 and the thin client device 400 may be provided in the sameoffice or on the same desk. In order to use the thin client device, auser registers on the server 410, for example, by inserting a card (e.g.JAVA card, a magnetic stripe card, etc.) into a reader on the device400. Thus, a transient user may register on the telephone 420 to obtainhot desking services whereby the PBX 430 associates his/her preferencesto the telephone (represented in FIG. 4 by the line between the thinclient server 410 and the PBX 430). The thin client server 410 accessesthe PBX 430 through an XML port or similar CTI interface in order to“hot desk” the user who has registered via the thin client device 400.In this context, PBX 430 provides the function of registrar 110 and thinclient server 410 provides the function of registration server 165 inFIGS. 1-3.

In the context of the exemplary method and system, it is contemplatedthat a user on the hot desked telephone 420 may wish to move anestablished call to his/her wireless device or to another hot deskedtelephone at another location, as in the example discussed above inconnection with Table 2. Thus, the user may remove the card from thereader, which results in de-registration being reported to the thinclient server 410 which, in response, ends the association between thethin client and the user. The thin client server 410 then reports thisde-registration to the PBX 430 through an XML or other CTI port forterminating the hot desking association between the user and thetelephone 420. However, according to an aspect of this specification thePBX 430 is provided with an application server (i.e. functionalitysimilar to that of server 120 in FIGS. 1-3) for running an appropriateECPL script (e.g. as set forth above in Table 2), by which userpreferences on handling the active call at the time of de-registrationmay be enforced.

In the event PBX 430 does not support ECPL or a similar policy system,an association may be set up between the line serving the hot deskedtelephone 420 and one of the lines serving the adjunct 440.Specifically, PBX 430 may set the hot desked telephone 420 as a lineappearance on one of the lines serving the adjunct 440. At the time ofde-registration, the thin client server 410 then informs both the PBX430 and the adjunct 440 of the user's action. As discussed above, thePBX 430 then ends the hot desking association. However, the adjunct 440invokes its line appearance so as to be conferenced with the existingcall. The adjunct 440 may perform this, for example, by simulating thesignalling of a conventional digital set over the line.

The adjunct 440 may therefore be equipped with an ECPL policy system ormay be provided a fixed mechanism of handling user preferences todetermine which endpoint a call exhibiting loss of association should bedirected (i.e. functionality similar to that of server 120 in FIGS.1-3). In one implementation, the adjunct 440 may use a conventional PBX‘transfer conference’ feature by signalling the PBX 430 that the call onthe line should be moved using a blind transfer to the appropriateendpoint. Alternately, the adjunct 440 may signal on another linecircuit requesting connection to desired endpoint and then make aninternal media connection between the original line carrying the callthat has exhibited loss of association and the line connected to thedesired end point.

Although the description of the configuration in FIG. 4 relates toregistration of a user on thin client device 400 so as to automatically“hot desk” the user on an associated telephone 420, it is also possiblefor hot desk registration of the user on PBX 430 to automaticallyregister the user on the associated thin client device 400 (i.e. theinterconnection between the PBX 430 and thin client server 410 can beused in the opposite direction to that described above). Thus, the hotdesking feature of the PBX 430 can be extended to signal the thin clientserver 410 to register the user on device 400.

In summary, a method and system are set forth for handling an existingcall in response to one of either an intentional or unintentional lossof association. According to an exemplary embodiment, a policy language(referred to herein as ECPL) executes user preferences in the event ofloss of association. One application of the exemplary embodiment relatesto handling loss of association in a configuration wherein a thin clientis coupled with a telephone to provide for association.

Persons skilled in the art will appreciate that there are yet morealternative implementations and modifications possible for implementingthe embodiments, and that the above implementations and examples areonly illustrations of one or more embodiments. For example, it iscontemplated that the policy language may include a policy indication torequest a decision from the user on how to handle a loss of associationduring the mid-call state. For example, an XML document may be providedwith possible options for handling loss of association and an element toinstruct the execution engine 140 respond in a manner appropriate to theuser device and user preference. The scope, therefore, is only to belimited by the claims appended hereto.

1. A system for transitioning an association between a user and a firstcommunication device involved in a call to at least one othercommunication device, comprising: means for generating a signal in theevent of a loss of said association in mid-call; and an applicationserver for receiving said signal and in response transitioning saidassociation to a second communication device.
 2. The system of claim 1,wherein said application server further includes an execution engine anda policy document for storing and executing user call handlingpreference scripts upon receiving said signal.
 3. The system of claim 2,wherein said policy document includes a mid-call element for delimitinguser preferences for handling of events during the mid-call state; anevent element for representing any one of a plurality of definedmid-call events; a location element for identifying said secondcommunication device; and a move element for transitioning saidassociation from said first communication device to said secondcommunication device specified by said location element.
 4. The systemof claim 3, wherein said policy document further includes a deviceelement having a mobility parameter for indicating mobile capabilitiesof said first communication device and said second communication device.5. The system of claim 1 wherein said association is meditated by atleast one of a registrar, a hot desking feature or wireless roaming. 6.The system of claim 3, wherein said move element further includes aconference parameter for transitioning said association from said firstcommunication device to said second communication device as a conferencewith at least one further user of at least one further communicationdevice.
 7. The system of claim 3, wherein said event element includes atype attribute for indicating at least one of said loss of association,unacceptable network performance, or DTMF reception events forinitiating transition of said association.
 8. The system of claim 3,wherein said policy document further includes a istant_switch elementfor facilitating said transition from said first communication device tosaid second communication device based on identity of at least one partyregistered to said second communication device.
 9. The system of claim3, wherein said location element includes a subsequent parameter forindicating said second communication device.
 10. The system of claim 3,wherein said location element includes a self parameter for indicatingthat said second communication device is registered in a contact listfor said user.
 11. A method of transitioning an association between auser and a first communication device involved in a call to at least oneother communication device, comprising: generating a signal in the eventof a loss of said association in mid-call; and receiving said signal andin response transitioning said association to a second communicationdevice.
 12. The method of claim 11, wherein said signal is generatedresponsive to user input.
 13. The method of claim 11, wherein saidsignal is generated responsive to at least one of a loss of connectionor the occurrence of unacceptable transmission performance at said firstcommunication device.
 14. A system, comprising: a thin client server; athin client device connected to said thin client server; at least onetelephone collocated with said thin client device; a PBX connected tosaid thin client server and to which said at least one telephone isconnected; a feature adjunct connected to said PBX and said thin clientserver; a card reader on said thin client device to receive a user cardfor one of either registering a user with said thin client server inresponse to which said thin client server registers said user on saidthin client device and causes said PBX to register said user on saidtelephone, or registering said user with said PBX which in responseregisters said user on said thin client device; and an applicationserver within one of said PBX and said adjunct for storing and executinguser call handling preferences in the event of a loss of associationduring a mid-call state between said collocated telephone and said thinclient device and at least one further communication device coupled tosaid PBX, to transition said association to a second communicationdevice.
 15. The system of claim 14, wherein said application servercauses said adjunct to transition said association by signalling saidPBX to perform a blind transfer of said association to said secondcommunication device.
 16. The system of claim 14, wherein said firstcommunication device is a wireless communication device and said systemfurther a wireless gateway for facilitating communication between saidwireless communication device and a data network, wherein a proxyestablishes a packet stream between said wireless gateway and said datanetwork, and wherein said system includes a digital signal processor forreceiving a copy of said packet stream from said proxy and detectingpoor voice performance thereon.
 17. The system of claim 16 wherein saiddigital signal processor includes a jitter buffer to receive said packetstream and indicates said poor voice performance in the event saidjitter buffer empties or the number of queued packets therein variesmore than a predetermined amount.
 18. The system of claim 14 whereinsaid PBX further includes a hot desking component for signalling saidthin client server to register the user on said thin client device.